home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group93b.txt / 000067_icon-group-sender _Fri May 7 20:55:51 1993.msg < prev    next >
Internet Message Format  |  1993-06-16  |  3KB
  1. Received: by cheltenham.cs.arizona.edu; Sat, 8 May 1993 05:49:45 MST
  2. Date: 7 May 93 20:55:51 GMT
  3. From: uchinews!ellis!goer@migs.ucar.edu  (Richard L. Goerwitz)
  4. Organization: University of Chicago
  5. Subject: Re: runtime debugger and the Icon fan club.
  6. Message-Id: <1993May7.205551.1831@midway.uchicago.edu>
  7. References: <9304281927.AA17778@roll.csd.sgi.com>, <1993Apr29.141749.24949@midway.uchicago.edu>, <1993May7.182643.26824@netlabs.com>
  8. Sender: icon-group-request@cs.arizona.edu
  9. To: icon-group@cs.arizona.edu
  10. Status: R
  11. Errors-To: icon-group-errors@cs.arizona.edu
  12.  
  13. lwall@netlabs.com (Larry Wall) writes:
  14. >
  15. >: [Icon programmers] mainly use the semicolon to separate two expres-
  16. >: sions abutted on the same line.  Generally it is lacking from idiomatic
  17. >: Icon code, and with good reason:  It is generally superfluous even in
  18. >: languages that force one to use it!
  19. >
  20. >Not to contradict a valid assertion, but as a point of interest it's
  21. >not superfluous in Perl, since it switches the lexer from expecting an
  22. >operator to expecting a term, just as any other operator would.
  23.  
  24. So, for example, if we see INTEGER 1, then OP '*', then INTEGER 1, if
  25. we then see a ';' the lexer knows that the next thing is not going to be an
  26. operator?  Maybe I'm not understanding, but wouldn't a newline accom-
  27. plish the same thing?
  28.  
  29.     1 * 1;
  30.     2 * 2...
  31.  
  32. vs.
  33.  
  34.     1 * 1
  35.     2 * 2...
  36.  
  37. Let's suppose I have a prefix operator '*' - the same string as the binary,
  38. right associative multiplication operator.  Will there be any problem
  39. inserting semicolons?  Not normally.  The third example below might
  40. pose a problem if we are simply *omitting* newlines and semicolons.  But
  41. the Icon tokenizer does not omit semicolons.  It inserts one if the end
  42. of every line that happens to coincide with the end of an expression:
  43.  
  44.     1) a * b * c
  45.  
  46.     2) a * * b
  47.  
  48.     3) a * b
  49.        * a * b
  50.  
  51. The natural way our eyes group 3 is the way Icon's tokenizer groups it,
  52. too.  The only problem with this method of handling semicolons is that
  53. you have to be careful not to break up expressions in such a way that
  54. the first part could be an expression.  For example if you want to say
  55. "a * b * c", then the following isn't a valid way of expressing this in
  56. using an Icon like system of semicolon insertion:
  57.  
  58.     4) a * b
  59.        * b
  60.  
  61. (4) is, of course, terrible programming style, if a * b * c is intended.
  62.  
  63. Occasionally, an Icon beginner (i.e. someone who doesn't yet have a feel
  64. for what Icon expressions should look like) will make mistakes like (4).
  65. These, however, are quickly remedied.  I can't recall grouping something
  66. wrong in this way for over five years (and I've used Icon for less than
  67. six years, I think).
  68.  
  69. Bottom line:  Icon doesn't omit semicolons.  Rather it inserts them ac-
  70. cording to a simple algorithm that lets the user pretty much forget about
  71. inserting them him or herself.
  72.  
  73. -- 
  74.  
  75.    -Richard L. Goerwitz              goer%midway@uchicago.bitnet
  76.    goer@midway.uchicago.edu          rutgers!oddjob!ellis!goer
  77.